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This  document  presents  the  system  design  specification  for  a  peacetime 


energy  emergency  reporting  system^  The  system  has  been  developed  for  the 


Office  of  the  Deputy  Assistant  Secretary  of  Defense  for  Logistics  and  Materiel 


Management,  and  specifically  for  the  Defense  Energy  Policy  Office,  which  is 


responsible  for  the  implementation  of  Department  of  Defense  (DoD)  energy 


policy. 


Vrhis  emergency  reporting  and  information  system  will  provide  DoD  manage¬ 


ment  with  the  information  to  respond  to  large-scale  peacetime  energy  disrup¬ 


tions.  (There  is  currently  no  system  to  assess  the  severity  of  peacetime 


energy  disruptions  for  the  DoD.)-\The  system  will  operate  in  a  manner  similar 


to  the  existing  Defense  Energy  Information  System  and  would  be  invoked  as 


required  during  an  emergency.  Data  reporting  would  be  limited  to  those 


installations  and  commodities  affected  by  the  emergency.  The  system 


provides:  1)  coverage  of  petroleum  and  non-petroleum  products,  fuel  types, 


2)  retail  and  wholesale  supply  data,  3)  timely  reporting  for  emergency  situa¬ 


tions,  4)  requirements  data  reporting,  and  5)  analysis  and  report  cap¬ 


abilities.  It  will  be  used  by  the  Defense  Energy  Policy  Office,  Service 


energy  offices,  and  Service  Control  Points_p  _ 

V  '  A. ardent  <y _Kiv. 

"This  System  Design  Specification  describes  the  syktem  functions,  data  ‘  4 


requirements,  operating  environment,  and  design  details  or(PEERSl  It  serves 


as  the  guide  for  the  persons  who  will  program  PEERS  and  adheres  to  the 


requirements  for  System  Specifications  in  the  "Automated  Data  Systems  Documen¬ 


tation  Standards,"  Department  of  Defense  (OASD-Comptroller) ,  7935. 1-S, 


September  1977. 
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SECTION  1 .  GENERAL 


1.1  Purpose  of  the  System  Specification. 

This  System  Specification  for  a  peacetime  energy  emergency  reporting 
system  is  written  for  the  Office  of  the  Assistant  Secretary  of  Defense  for 
Manpower,  Reserve  Affairs  and  Logistics  (OASD(MRA&L)) ,  to  fulfill  the 
following  objectives: 

-  to  provide  detailed  definition  of  system  functions 

-  to  communicate  details  of  the  ongoing  analysis  to  appropriate  opera¬ 
tional  and  development  personnel 

-  to  define  in  detail  interfaces  with  other  systems  and  subsystems  and 
the  facilities  to  be  used  for  accomplishing  those  interfaces. 

In  this  document,  the  system  will  be  referred  to  as  the  Peacetime  Energy 
Emergency  Reporting  System  (PEERS). 

1.1.1  Purpose  and  Scope. 

The  purpose  of  this  System  Specification  is  to  specify  the  PEERS  system 
design.  It  is  written  using  the  "Automated  Data  Systems  Documentation  Stand¬ 
ards,"  Department  of  Defense  (OASD-Comptroller) ,  7935. 1-S,  September  1977,  as 
a  guideline  and  contains  the  following  sections: 

-  Section  1--General  Information.  This  section  provides  an  introduction 
to  PEERS,  a  list  of  related  reference  documents,  and  a  list  of  terms 
and  acronyms  used  in  the  document. 

-  Section  2 — Summary  of  Requirements .  This  section  presents  a  general 
description  of  PEERS  and  specifies  how  its  functions  satisfy  the 
operational  requirements  goals.  This  section  also  specifies  system 
performance  in  the  areas  of  accuracy  and  validity  of  data,  scheduling 
and  timing,  and  system  flexibility. 

-  Section  3 — Environment.  This  section  describes  the  equipment,  support 
software,  and  system  interfaces  of  the  PEERS  environment. 

-  Section  A — Design  Details.  This  section  specifies  the  PEERS  design 
details.  It  includes  system  functional  capabilities,  design  approach 
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and  logic  flow,  processing  required  to  support  each  function,  defini¬ 
tion  of  the  inputs  and  outputs  for  each  function,  and  the  computer 
program  flow  of  each  function. 

1.1.2  Functions  and  Capabilities. 

PEERS  is  a  "standby"  emergency  reporting  and  information  system  which 
will  provide  DoD  management  with  the  information  to  respond  to  large-scale 
peacetime  energy  disruptions.  It  will  operate  in  a  manner  similar  to  the 
existing  Defense  Energy  Information  System  (DEIS)  and  would  be  invoked  as 
required  during  an  emergency.  Data  reporting  can  be  limited  to  those 
installations  and  energy  products  affected  by  a  particular  emergency.  The 
system  will  provide: 

-  Coverage  of  Petroleum  and  Non-Petroleum  Products.  PEERS  will  contain 
inventory  and  consumption  data  for  the  bulk  petroleum  products  covered 
by  DEIS-I  and  the  utility  energy  products  covered  by  DEIS-II.  Data 
will  be  collected  only  for  those  products  in  short  supply  during  an 
emergency. 

-  Retail  and  Wholesale  Visibility.  PEERS  will  collect  and  report  energy 
supply  and  demand  data  from  over  1,400  DoD  retail  and  wholesale 
locations . 

-  Timely  Reporting.  PEERS  will  have  the  capability  to  collect  and 
report  data  as  required,  weekly,  biweekly,  daily,  etc. 

-  Essential  Data  Elements.  PEERS  will  include  inventory,  anticipated 
receipts,  and  consumption  data  from  each  reporting  location  for  each 
product  of  concern. 

-  Powerful  Analysis  and  Report  Capabilities.  PEERS  will  use  the  same 
data  base  management  system  (DBMS)  as  DEIS.  This  generalized 
DBMS  will  provide  extensive  analytical  capabilities  to  generate 
reports  tailored  to  a  particular  emergency. 

PEERS  will  be  used  by  the  Defense  Energy  Policy  Office,  Service  energy 
offices,  and  Service  Control  Points  (for  petroleum).  Its  reports  will  be  used  • 

to  assess  the  severity  of  energy  shortages,  provide  feedback  on  energy  con¬ 
servation  efforts,  and  answer  Congressional  and  Department  of  Energy 
information  requests. 
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1. 1.2.1  Organizational  Responsibilities. 


sq 


The  Defense  Energy  Policy  Office,  under  the  Deputy  Assistant  Secretary 
of  Defense  (DASD)  for  Logistics  and  Materiel  Management  (L&MM) ,  Energy  and 
Transportation  (ET) ,  has  overall  project  management  responsibility  for  PEERS. 
The  Defense  Energy  Data  Analysis  Panel  (DEDAP)  includes  the  Services  and 
provides  a  forum  for  discussion  of  energy  management  information  needs. 

The  Air  Force  Data  Services  Center  (AFDSC)  will  provide  programming, 
implementation,  and  operational  support  for  the  PEERS  functions  in  this  System 
Specification.  The  Management  Information  and  Analysis  Division  of  the  Office 
of  the  Comptroller,  Defense  Fuel  Supply  Center  (DFSC-CB) ,  will  be  the  PEERS 
system  operator. 

1.1. 2. 2  Software  Capabilities. 


PEERS  is  designed  to  function  within  the  current  DEIS  data  collection  and 
reporting  environment  although  the  data  processing  system  will  be  new.  PEERS 
software  capabilities  will  include  the  initial  generation  of  header  informa¬ 
tion  and  tables  from  DEIS-I  and  DEIS-II  data  bases,  data  edit,  input,  loading 
and  maintenance  of  the  PEERS  data  base,  and  production  of  standard  and  ad  hoc 
energy  reports. 

1.2  Project  References. 

PEERS  is  designed  to  be  very  similar  to  DEIS  so  as  to  use  existing  files 
and  processing  flows.  Consequently,  this  design  specification  draws  heavily 
on  previous  DEIS  studies  and  design  documents.  Only  the  more  recent  and 
pertinent  documents  are  cited  here;  a  more  complete  summary  of  the  references 
applicable  to  the  history  and  development  of  DEIS  is  contained  in  the  DEIS 
System  Design  Specification:  "Defense  Energy  Information  System  (DEIS): 
DEIS-80  System  Design  Specifications,"  Logistics  Management  Institute,  DP103, 
July  1982. 


1.2.1  Logistics  Management  Institute  Documentation. 

"Defense  Energy  Information  System  (DEIS):  Recommended  Design  Modifica¬ 
tion,"  Logistics  Management  Institute,  ML809,  June  1979. 

"Defense  Energy  Information  System  (DEIS) :  Current  System  Documenta¬ 
tion,"  Logistics  Management  Institute,  ML917,  March  1980. 

"Defense  Energy  Information  System  (DEIS) :  DEIS-80  System  Design  Spe¬ 
cification,"  Logistics  Management  Institute,  DP103,  July  1982. 

"Peacetime  Energy  Emergency  Reporting  System,"  Logistics  Management 
Institute,  Memorandum  Report  ML301,  August  1983. 

1.2.2  Other  Related  References. 

"Defense  Energy  Information  System,"  Department  of  Defense,  DoD 
5126.46-M,  December  21,  1982. 

"Automated  Data  Systems  Documentation  Standards,"  Department  of  Defense, 
(OASD-Comptroller) ,  7935. 1-S,  September  13,  1977. 

1.3  Terms  and  Acronyms. 

The  following  terms  and  acronyms  have  been  used  in  this  report. 

1.3.1  Terms. 

Back-Up  Copy:  A  copy  of  a  file  or  data  set  that  is  kept  for  reference  in 
case  the  original  file  or  set  is  destroyed. 

Back-Up  Procedures:  Procedures  which  allow  systems  to  be  restored  and 
interrupted  processing  to  resume  while  maintaining  system  integrity. 

Batch  Processing:  Pertaining  to  the  control  technique  of  grouping  com¬ 
puter  programs  or  data  for  input  to  a  computer  system  for  handling  at  the 
same  time. 

Data  Base:  The  collection  of  computer-stored  data  which  is  accessed  by  a 
processing  system  and  is  fundamental  to  the  performance  of  the  capabili¬ 
ties  of  that  system. 

Data  Base  Administrator:  The  person  responsible  for  the  efficient 

organization  and  operation  of  the  data  base. 

Data  Element:  A  group  of  characters  that  specify  an  item,  for  instance, 
"month."  A  data  element  contains  no  subordinate  items. 
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File :  One  or  more  records  concerning  places  or  things  that  are  closely 

related  and  handled  together  for  processing. 


Function:  One  of  several  individual  processes  performed  by  a  computer 

program,  for  instance,  sorting  a  data  base. 

Interactive  Processing:  Pertaining  to  processing  in  which  each  entry 
elicits  a  response. 

Macro:  A  single  computer  instruction  that  represents  a  sequence  of 
computer  commands.  Macros  allow  a  user  to  execute  a  sequence  of  complex 
computer  instructions  with  a  single  command. 

On-Line:  (1)  Pertaining  to  equipment  or  devices  under  control  of  the 

computer;  (2)  Pertaining  to  a  user’s  ability  to  give  the  computer 
instructions  and  receive  output  without  delay.  Interactive  processing  is 
one  type  of  on-line  activity. 

Query:  A  request  for  specific  data  during  interactive  processing.  The 

request  involves  selecting  specified  data  and  manipulating  it  by  sorting, 
summary,  etc. 

Record:  A  set  of  data  elements  closely  related  in  the  sense  that  they 
pertain  to  the  same  place  or  thing.  An  example  is  a  "DoDAAC  product 
record",  which  contains  consumption  information  about  a  particular  pro¬ 
duct  at  one  DoD  activity. 

Software:  Computer  programs  or  routines  prepared  by  computer  profes¬ 

sionals  to  simplify  and  facilitate  the  use  of  the  computer. 

Subsystem:  A  coordinated  group  of  components  which  form  a  secondary  or 

subordinate  system  usually  capable  of  operating  independently  of,  or 
asynchronously  with,  a  controlling  system. 

System:  A  coordinated  organization  of  people,  hardware,  methods  and  pro¬ 
cedures  that  operate  together  to  achieve  a  predetermined  set  of 
objectives . 

1.3.2  Acronyms. 

AFDSC 

ASD(MRASlL) 

DASD(LSMM) 


DBA 

DBMS 

DEDAP 


Air  Force  Data  Services  Center 

Assistant  Secretary  of  Defense  (Manpower,  Reserve 
Affairs  and  Logistics) 

Deputy  Assistant  Secretary  of  Defense  (Logistics  and 
Materiel  Management) 

Data  Base  Administrator 

Data  Base  Management  System 

Defense  Energy  Data  Analysis  Panel 


DEIS 


Defense  Energy  Information  System 
Petroleum  Products  Portion  of  DEIS 


DEIS- I 

DEIS-II  -  Utility  Energy  Usage  Portion  of  DEIS 

DFSC  -  Defense  Fuel  Supply  Center 

DFSC-CB  -  DFSC,  Office  of  Comptroller,  Management  Information  & 

Analysis  Division 

DLA  -  Defense  Logistics  Agency 

DoD  -  Department  of  Defense 

DoDAAC  -  DoD  Activity  Address  Code 

OASD  -  Office  of  the  Assistant  Secretary  of  Defense 

PEERS  -  Peacetime  Energy  Emergency  Reporting  System 
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SECTION  2.  SUMMARY  OF  REQUIREMENTS 


The  design  of  PEERS  is  based  on  the  requirements  identified  in  the 
"Peacetime  Energy  Emergency  Reporting  System,"  Logistics  Management  Institute, 
Memorandum  Report  ML301,  August  1983.  It  also  draws  heavily  on  the  DEIS 
procedures  and  capabilities  detailed  in  "Defense  Energy  Information  System 
(DEIS):  DEIS-80  Design  System  Specification,"  Logistics  Management  Institute, 
DP103,  July  1982.  This  section  describes  PEERS,  its  functions,  and  its 
performance  requirements. 

2.1  System  Description. 

PEERS  is  a  "standby"  emergency  reporting  and  information  system  which 
will  provide  DoD  management  with  the  information  to  respond  to  large-scale 
peacetime  energy  disruptions.  It  will  operate  in  a  manner  similar  to  the 
existing  DEIS  and  would  be  invoked  as  required  during  an  emergency.  Data 
reporting  can  be  limited  to  those  installations  and  energy  products  affected 
by  the  emergency. 

The  system  will  provide  inventory  and  consumption  data  for  petroleum  and 
non-petroleum  products  such  as  natural  gas  and  electricity  and  visibility  of 
both  retail  and  wholesale  installations.  PEERS  is  designed  to  function  within 
the  current  DEIS  data  collection  and  reporting  environment  although  the  data 
processing  system  will  be  new.  PEERS  data  will  be  transmitted  to  DLA  using 
AUTODIN  or  the  DoD  message  communication  system.  Revised  instructions  and 
formats  will  be  published  as  an  addendum  to  the  DEIS  User's  Manual  (DoD 
5126.46-M). 


PEERS  will  use  the  same  DBMS  (INQUIRE1)  used  in  DEIS.  INQUIRE  allows 
* 

non-programmers  to  "query"  the  data  base,  that  is,  to  extract  selected  DEIS 
data  that  was  previously  stored.  The  ability  to  create  queries  and  receive 
timely  responses  is  essential  to  management  of  an  emergency.  PEERS  will  be 
used  by  the  Defense  Energy  Policy  Office,  Service  energy  offices,  and  Service 
Control  Points  (for  petroleum).  Its  reports  will  be  used  to  assess  the 
severity  of  energy  shortages,  provide  feedback  on  energy  conservation  efforts, 
and  answer  Congressional  and  Department  of  Energy  information  requests. 

The  Defense  Energy  Policy  Office  has  overall  project  management  respon¬ 
sibility  for  PEERS.  The  AFDSC  will  provide  programming,  implementation,  and 
operational  support  for  the  development  of  PEERS.  DFSC-CB,  the  DEIS  system 
operator,  will  also  be  the  PEERS  system  operator.  Figure  2-1  shows  the 
organizational  responsibilities  for  these  PEERS  functions. 

2.2  System  Functions. 

This  subsection  addresses  both  the  manual  and  automated  functions 
designed  to  meet  PEERS  requirements.  Each  of  the  automated  functions  will  be 
described  in  greater  detail  in  Section  4.  The  following  functions  are  dis¬ 
played  in  the  system  flowchart  in  Figure  2-2.  The  subsection  numbers,  where 
applicable,  are  noted  on  the  flowchart. 

2.2.1  Generate  PEERS  Header  File. 

Upon  invocation  of  PEERS,  the  Defense  Energy  Policy  Office  will  provide 
criteria  for  selecting  the  DoD  activities  required  to  report.  From  these 
selection  criteria  (e.g.,  all  DoDAACs  in  California),  a  header  file  will  be 
generated  from  the  DEIS-I  and  DEIS-II  header  files,  using  the  INQUIRE  query 
language.  This  file  will  contain  a  header  record  for  each  DoDAAC  selected  to 

Enquire  was  developed  and  is  maintained  and  copyrighted  by  Infodata 
Systems,  Inc.,  Falls  Church,  VA.  The  AFDSC  has  purchased  it. 
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FIGURE  2-1.  ORGANIZATIONAL  RESPONSIBILITIES  FOR  PEERS  DATA 


AUTODIN  OR 


STANDARD  MESSAGE  FORMAT 


DATA  PREPROCESSING 


OATA  PROCESSING 


OATA  MANAGEMENT 


OATA  REPORTS 


FIGURE  2-2.  PEERS  SYSTEM  FLOW 
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report.  The  format  of  this  header  record  will  be  identical  to  that  used  in 
DEIS-I  and  DEIS-II  (see  Appendix  A  for  the  definitions  and  format  of  the 
header  data  elements). 

2.2.2  PEERS  Data  Collection. 

When  PEERS  is  invoked,  the  Defense  Energy  Policy  Office,  in  conjunction 
with  the  Services,  will  specify:  1)  when  PEERS  reporting  is  to  commence,  2) 
which  DoD  activities  will  report,  3)  the  products  to  be  reported,  and  4)  the 
frequency  of  the  required  reports.  The  selected  DoD  activities  will  collect 
and  transmit  the  required  data  directly  to  DLA  using  AUTODIN  or  the  DoD 
message  communication  system.  Appendix  B  contains  the  card  layouts  for  each 
of  the  input  forms. 

2.2.3  Edit  and  Convert  Data. 

PEERS  data  will  be  collected  and  reported  to  DLA  over  the  AUTODIN  system. 
They  will  be  separated  from  DEIS  data  and  other  traffic  at  DLA  and  written  to 
a  PEERS  data  file. 

All  data  will  be  edited.  The  edits  will  include  checks  for  missing  data, 
correct  format,  and  form  (alphabetic  or  numeric).  Data  items  passing  the 
edits  will  be  added  to  the  data  base.  Records  containing  data  items  which 
fail  the  edits  will  be  placed  on  a  Rejection  File.  Outputs  from  the  edit 
function  will  be:  1)  a  list  of  records  with  possible  errors,  and  a  list  of 
activities  not  reporting  or  reporting  significantly  different  product  usage; 
2)  a  Rejection  File  containing  erroneous,  out-of-date,  or  questionable  data; 
and  3)  an  Update  File  (or  data  base)  containing  accepted  records.  Error 
statistics  will  be  collected  and  reported  to  the  system  operator  (DFSC-CB) . 

PEERS  will  provide  the  capability  to  correct  and  resubmit  records  on  the 
Rejection  File,  to  change  items  in  the  data  base,  and  to  submit  new  data 
records  for  editing  and  updating  the  data  base.  All  on-line  corrections  and 


updates  will  be  entered  on  the  Correction  File  for  re-editing  before  data  base 
updating. 

2.2.4  Update  Data  Base. 

The  PEERS  capability  to  process  and  verify  potentially  large  amounts  of 
data  will  be  obtained  through  use  of  a  generalized  DBMS.  There  are  no  pro¬ 
gramming  requirements  for  developing  the  DBMS,  since  INQUIRE  will  be  used. 
INQUIRE  has  the  following  capabilities  and  features: 

-  multiple  user  on-line  access 

host  language  interface  to  the  programming  language  to  be  used  for 
applications  programs 

restart/recovery  procedures  for  system  crashes 

-  ability  to  add  new  data  fields  (non-keyed)  to  existing  data  base 
records 

-  batch  update  capabilities  via  host  language  program 

-  on-line  query  and  report  generation  capabilities. 

The  actual  data  base  update  will  be  performed  through  the  generalized 
DBMS  capabilities  and  will  apply  records  with  correct  data  to  the  data  base. 
Such  features  of  the  DBMS  as  the  ability  to  log  updates  automatically  and 
create  a  Rejection  File  of  records  thought  to  be  in  error  will  also  be  used  in 
conjunction  with  the  data  base  update. 

In  the  future,  the  need  to  add  or  delete  new  data  files  or  otherwise  re¬ 
organize  the  data  base  may  occur.  The  features  of  the  DBMS  will  permit  such 
updating,  should  it  become  necessary. 

2.2.5  Generate  Ad  Hoc  Reports. 

Obviously,  PEERS  will  not  produce  a  series  of  standard  reports  on  a 
regularly  scheduled  basis.  Reports  specifically  tailored  to  an  emergency  can 
rapidly  be  prepared  using  the  query  language  capability  of  the  DBMS.  They  can 
be  accessed,  using  an  on-line  computer  terminal,  by  the  Services,  MRA&LCL&MM) , 
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and  others  as  specified  by  the  Defense  Energy  Policy  Office.  In  addition,  all 
data  in  the  PEERS  data  base  will  be  accessible  to  authorized  users  for 


generation  of  special,  one-time,  or  new  reports  (i.e.,  ad  hoc  reports). 
Through  use  of  the  generalized  DBMS,  the  report  generation  function  will 
provide  an  easy-to-use,  interactive  capability  to  access,  retrieve,  format, 
and  print  data.  Interface  to  data  reduction  and  statistical  functions  will 
also  be  provided.  The  final  output  will  be  directed  to  the  terminal  originat¬ 
ing  the  request  or  to  a  specified  hard-copy  printer  as  the  requester  chooses. 
The  requester  may  also  choose  to  save  the  symbolic  language  statements  which 
comprise  a  report  request  so  that  the  same  report  or  a  modified  version  may  be 
requested  later  with  minimal  effort. 

2.2.6  Delete  Outdated  Data. 

The  PEERS  on-line  data  base  will  consist  of  report  data  for  the  most 
recent  five  weeks.  This  will  provide  at  least  a  one-week  overlap  with  the 
most  recent  DEIS  report.  There  is  no  need  to  retain  any  PEERS  reports  beyond 
five  weeks,  since  the  same  information  will  be  maintained  in  even  greater 
detail  in  the  DEIS  data  base.  Thus,  the  on-line  data  base  will  be  updated 
periodically,  and  the  outdated  data  will  be  deleted  using  the  INQUIRE  programs 
and  procedures. 

2.3  Accuracy  and  Validity. 

There  will  be  several  ways  to  ensure  the  accuracy  and  validity  of  PEERS 
data.  Manual  procedures  and  controls  similar  to  those  used  in  DEIS  will 
increase  the  likelihood  of  complete  and  accurate  data  being  collected  and 
recorded  for  all  reporting  DoD  activities.  Data  transmission  errors  will  be 
minimized  through  the  use  of  AUTODIN  (specifically  AUTODIN-I).  A  number  of 
syntax,  format,  and  value  edits  will  be  performed  by  the  automated  system  when 
new  transactions  are  added  to  the  data  base.  A  final,  manual  check  on  the 
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data  will  be  performed  by  persons  who  will  inspect  and  evaluate  the  results  of 
the  submissions. 

2.3.1  Manual  Procedures. 

PEERS  data  collection  procedures  will  be  specified  in  an  addendum  to  DoD 
5126.46-M  instructions.  PEERS  will  use  the  same  reporting  channels  as  DEIS, 
and  the  PEERS  data  elements  are  a  subset  of  the  DEIS  data  elements.  Thus,  the 
PEERS  reporters  will  be  familiar  with  definitions  and  procedures  for 
reporting.  Command  attention  during  an  energy  emergency  should  insure  the 
data  accuracy. 

2.3.2  Data  Transmission. 

As  with  DEIS,  PEERS  reporting  will  use  the  AUTODIN-I  communication  system 
wherever  available.  AUTODIN  contains  parity  error  detection  and  correction 
routines  which  are  superior  to  those  used  in  the  teletype-based  DoD  message 
communication  system.  PEERS  will  be  able  to  accept  data  from  either  system. 

2.3.3  Automated  Edits  and  Calculations. 

Various  data  edits  will  be  performed  automatically  when  new  PEERS  trans¬ 
actions  are  added  to  the  data  base.  All  required  data  items  will  be  examined 
to  verify  the  presence  of  data.  All  data  will  be  verified  for  format  (numeric 
or  alphabetic)  and  value,  as  specified  in  the  PEERS  data  dictionary  in 
Appendix  A. 

Due  to  the  short  turnaround  required  for  PEERS  reporting,  extensive 
editing  and  validation  will  not  be  possible.  Obvious  errors  and  questionable 
data  will  be  eliminated,  but  there  will  not  be  time  for  lengthy  follow-up  as 
in  DEIS.  A  list  of  reporting  errors  will  be  submitted  to  each  Service  energy 
office.  These  offices  will  take  appropriate  action  to  ensure  accurate  data  is 
submitted  for  the  next  reporting  period  (e.g.,  the  next  day  or  next  week). 


Calculations  in  PEERS  will  be  limited  to  summary  (totals)  calculations. 
In  general,  these  calculations  will  result  in  a  whole  number;  however,  should 
arithmetic  operations  result  in  more  than  the  required  accuracy,  all  amounts 
with  a  number  greater  than  or  equal  to  five  in  the  next  significant  decimal 
place  will  be  rounded  up,  and  all  amounts  with  a  number  less  than  five  in  that 
decimal  position  will  be  truncated  either  to  two  decimal  places  or  to  a  whole 
number,  as  appropriate. 

2.3.4  Scheduling  and  Timing. 

PEERS  scheduling  and  timing  will  depend  on  the  frequency  and  extent  of 
the  reporting  specified  by  the  Defense  Energy  Policy  Office.  National 
emergencies,  with  numerous  DoDAACs  reporting,  will  require  more  processing, 
editing,  and  validation  than  a  more  localized  emergency.  The  Defense  Energy 
Office  will  specify  an  asset  cut-off  time  and  date,  such  as  0800  Friday,  and 
reporting  DoDAACs  will  measure  inventory  and  consumption  as  of  that  time.  The 
Energy  Office  will  also  specify  a  date  and  time  by  which  the  required  DoDAAC 
report  must  be  received.  DLA  will  edit  and  verify  to  the  maximum  extent 
feasible,  given  the  amount  of  data  reported  and  the  frequency  of  the  reports. 
After  editing,  accepted  data  will  be  loaded  into  the  PEERS  data  base,  either 
the  same  day  or  overnight.  The  corrected  data  will  then  be  edited  and  applied 
to  the  data  base  by  a  batch  job  initiated  by  the  system  operator.  Much  of  the 
batch  updating  will  be  completed  overnight  (as  AFDSC  scheduling  permits). 
Depending  on  the  volume  of  update  transactions,  the  system  operator  may  re¬ 
quest  overnight  processing  or  processing  that  should  be  completed  within  two 
to  three  hours.  At  this  point  the  data  will  be  available  for  on-line  queries 
and  reports.  There  will  be  very  little  time  for  processing  late  reports  or 
extensive  on-line  editing  as  with  DEIS.  Depending  on  the  extent  of  the 
emergency,  on-line  activity  may  be  as  much  as  eight  hours  per  day  during  this 


emergency  reporting  period. 


Ad  hoc  reports  and  queries  will  be  provided  within  a  few  minutes  to  four 
hours,  depending  on  the  complexity  of  the  request  and  whether  the  output  is 
directed  to  the  originating  terminal  or  to  a  printer.  Simple  queries,  such  as 
those  requiring  no  sorting  and  output  of  less  than  500  lines,  will  be  provided 
within  15  minutes  under  normal  circumstances.  Queries  which  result  in  sort¬ 
ing,  extensive  accumulation  of  data,  and  a  larger  amount  of  output  will  be 
provided  within  four  hours. 

2.4  Flexibility. 

Use  of  a  generalized  DBMS  is  the  key  to  PEERS.  The  DBMS  provides  the 
flexibility  which  will  enable  PEERS  to  respond  to  the  uncertain  information 
requirements  of  an  energy  emergency.  The  capability  to  rapidly  and  easily 
develop  ad  hoc  reports  specifically  tailored  for  the  type  of  emergency 
encountered  is  vital  to  an  energy  emergency  information  system.  In  addition, 
the  DBMS  will  permit  integration  of  new  data  elements  as  they  become  relevant 
to  PEERS  users,  easy  creation  of  on-line  queries  and  corrections,  and  powerful 


analytical  capabilities. 


."V 


SECTION  3 .  ENVIRONMENT 


This  section  describes  the  computer  hardware  and  software  capabilities 
required  for  the  operation  of  PEERS,  interface  requirements  with  DEIS  and  the 
DLA  computer  center,  and  security  and  privacy  considerations. 

3.1  Equipment  Environment. 

PEERS  will  operate  in  the  same  environment  as  DEIS  and  use  the  same  com¬ 
puter  equipment  and  support  software.  Although  PEERS  will  not  require  any 
additional  hardware  or  support  capabilities,  it  will  require  additional 
processing  time.  As  with  DEIS,  PEERS  will  depend  on  unclassified  equipment  at 
AFDSC  for  the  bulk  of  its  data  processing.  For  optimal  processing  using  the 
INQUIRE  DBMS,  at  least  three  separate  disks  should  be  available  for  data  base 
storage  of  the  header,  search,  and  index  files. 

The  size  of  the  PEERS  data  base  will  depend  on  the  number  of  DoDAACs 
which  are  required  to  report  and  also  on  the  number  of  product  types  for  which 
data  are  to  be  collected.  In  a  worst-case  situation,  daily  data  for  all 
1400  DEIS  reporters  and  all  DEIS-I  and  DEIS-II  products  might  be  collected. 
Based  on  the  size  of  the  data  dictionary  for  PEERS  (see  Appendix  A),  it  is 
estimated  that  the  PEERS  data  base  could  contain  60.4  million  characters  in 
this  worst-case  scenario.  A  more  likely  worst-case  scenario  would  call  for 
U.S.  installations  to  report  weekly  for  particular  fuel  types,  for  instance, 
natural  gas  or  automotive  gasolines.  The  data  base  might  contain  as  many  as 
2.5  million  characters  in  this  case.  These  estimates  do  not  include  any 
overhead  required  by  the  DBMS,  which  may  require  50  percent  more  disk  space. 
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In  addition  to  the  computer  mainframe,  the  following  equipment  will  be 
utilized: 

-  Communications  network:  PEERS  input  data  will  be  transmitted  over 
AUTODIN-I  or  the  DoD  message  communication  network  (teletype- 
compatible  terminals)  in  most  instances. 

-  DLA  computer  center:  PEERS  data  will  be  transmitted  to  DLA’s  computer 
center  where  magnetic  tapes  of  the  data  will  be  transmitted  to  the 
AFDSC  computer. 

-  I/O  devices:  The  system  operator  requires  three  to  four  terminals 

(preferably  bisynchronous  CRT)  for  entry  of  data  and  queries.  In 
addition,  the  system  operator  needs  a  300-line-per-minute  printer  for 
small  error  reports  and  queries.  The  Defense  Energy  Policy  Office 

requires  one  terminal  (portable,  hard  copy)  for  queries.  It  is 
expected  that  not  more  than  three  terminals  will  be  accessing  the 
PEERS  data  base  at  any  one  time.  The  equipment  now  used  for  DEIS  is 
sufficient  for  PEERS. 

3.2  Support  Software  Environment. 

PEERS  will  require  the  same  support  software  as  DEIS;  this  software  is 
already  available  at  AFDSC  and  DLA  and  includes  the  following: 

-  an  operating  system 

-  a  high-level  programming  language  (COBOL) 

-  communications  software  (to  monitor  and  ensure  accuracy  of  data 
transmission) 

-  data  base  management  software  (INQUIRE) 

-  software  similar  to  IBM's  Systems  Productivity  Facilities  (to  enhance 
on-line  editing  capabilities). 

This  support  software  provides  the  basis  for  AFDSC  to  produce  the  PEERS 
application  software. 

3.3  Interfaces. 

3.3.1  Interface  with  DEIS. 

PEERS  will  obtain  its  header  file  data  directly  from  the  DEIS-I  and 
DEIS-II  header  files  for  those  DoDAACs  required  to  report.  In  addition,  PEERS 
will  require  access  to  DEIS  for  historical  energy  consumption  data  and  the 
building,  personnel,  and  weather  data  maintained  in  the  DEIS-II  data  base. 
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INQUIRE,  the  DBMS  under  which  PEERS  and  DEIS  operate,  facilitates  the  transfer 
of  such  data  with  its  multi-data  base  capabilities.  The  DEIS  and  PEERS  data 
bases  will  be  connected  through  the  common  DoDAAC  data  element.  Any  updates 
to  DEIS  header  data  during  PEERS  reporting  will  also  be  processed  on  the  PEERS 
header  data.  Current  data  formats  for  the  DEIS  data  are  specified  in  the  DEIS 
System  Design  Specification:  "DEIS-80  System  Design  Specifications," 

Logistics  Management  Institute,  DP103,  July  1982. 

3.3.2  Interface  with  DLA. 

PEERS  will  interface  with  the  DLA  computer  center  in  the  same  manner  as 
DEIS.  The  DLA  computer  center  will  provide  tapes  containing  PEERS  data 


submitted  through  AUTODIN,  DoD's  message  communication  system,  or  hard  copy. 
These  may  include  data  which  have  undergone  pre-processing  by  any  of  the 
Services .  Service  data  submitted  on  magnetic  tape  will  have  to  be  in  the  same 
form  as  those  produced  by  DLA  for  AFDSC,  that  is,  they  must  contain  PEERS  data 
card  images  as  described  in  Appendix  B. 

During  an  actual  peacetime  energy  emergency  the  PEERS  routing  indicator 
may  be  changed  so  that  data  come  directly  to  AFDSC.  This  would  save  the  time 
needed  to  transmit  the  data  from  DLA  to  AFDSC. 

3.4  Security  and  Privacy. 

PEERS  will  contain  no  classified  information  and  no  information  on  indi¬ 
viduals  and,  therefore,  will  not  have  any  specific  privacy  and  security 
requirements.  Both  PEERS  and  DEIS  are  unclassified  systems;  consequently, 
there  will  be  no  security  considerations  in  transferring  data  from  DEIS  to 
PEERS.  Procedures  to  ensure  the  integrity  of  the  data  base  are  discussed  in 


3.5  Controls. 


Once  PEEKS  implementation  is  substantially  completed,  the  Defense  Energy 
Policy  Office  will  be  the  focal  point  for  policy  concerning  operational 
control  of  the  system.  This  office  will  specify: 

-  commencement  and  termination  of  PEERS  reporting 

-  frequency  of  PEERS  reports 
reporting  DoDAACs 

-  product  types  to  be  reported  under  PEERS. 

The  Defense  Energy  Policy  Office  has  also  delegated  the  function  of  the  Data 

Base  Administrator  (DBA)  to  the  system  operator  (DFSC-CB) . 

The  major  required  DBA  functions  are: 

review  of  inputs  to  ensure  completeness  and  accuracy  of  data  sub¬ 
missions;  due  to  the  increased  frequency  of  reporting  during  an  emer¬ 
gency,  manual  data  edits  are  likely  to  be  substantially  less  compre¬ 
hensive  than  under  DEIS.  In  a  large-scale  emergency  with  numerous 
reporting  DoDAACs,  there  will  be  insufficient  time  to  correct  anything 
but  the  most  obvious  errors 

-  consultation  with  users  and  AFDSC  to  determine  if  data  base  contents 
or  organization  require  change 

review  of  data  base  and  system  statistics 

-  control  over  initiation  of  update  runs  and  restart/ recovery 
procedures . 


SECTION  4.  DESIGN  DETAILS 


The  overall  requirement  for  PEERS  is  to  provide  DoD  management  with  the 
information  to  respond  to  large-scale  peacetime  energy  disruptions.  With  this 
as  a  guideline,  the  following  requirements  were  developed.  First,  PEERS  data 
will  be  maintained  on  an  unclassified  system  and  use  a  DBMS  that  supports 
on-line  queries  through  standard  data  base  retrieval  routines.  Second,  the 
DBMS  will  provide  the  capability  to  add  or  delete  data  element  fields  when  new 
requirements  arise.  Third,  data  entry  will  be  easy  for  users  yet  controllable 
by  PEERS  managers.  Fourth,  data  editing,  including  both  format  and  reason¬ 
ableness  criteria,  will  provide  increased  accuracy.  Finally,  analytical 
capabilities  will  be  provided  to  allow,  on  very  shot  notice,  the  development 
of  reports  tailored  to  a  given  energy  emergency.  The  specific  functions 
designed  to  meet  these  requirements  are  described  in  the  following  paragraphs. 
4.1  General  Operating  Procedures. 


4.1.1  Data  Requirements . 

The  capability  must  be  provided  to  input  PEERS  data  on-line  to  the  Cor¬ 
rection  File  as  well  as  from  cards  and  card  images  on  magnetic  tape.  Edit 
procedures  will  prevent  double  entry  of  data;  duplicate  records  will  be 
printed  on  an  error  report  (called  a  Transaction  Proof  Listing) . 

All  data  submitted  from  a  field  activity  will  be  handled  as  an  add  trans¬ 


action  unless  data  for  the  same  date,  DoDAAC,  and  product  code  exist  in  the 
data  base.  DFSC-CB  will  retain  a  listing  of  the  original  data  submitted  from 
the  field  activities  for  five  weeks,  either  on  the  DD173  message  form  or  a 
listing  of  validated  punched  cards  received  via  AUTODIN. 


4.1.2  System  Scheduling  Requirements. 


PEERS  scheduling  and  timing  will  depend  on  the  frequency  and  extent  of 
reporting.  Table  4-1  summarizes  the  processing  cycle  for  PEERS  under  some 
likely  reporting  frequencies.  The  Defense  Energy  Office  will  specify  an  asset 
cut-off  time  and  date  at  which  reporting  DoDAACs  will  measure  inventory  and 
consumption.  The  Energy  Office  will  also  specify  a  time  and  date  by  which  the 
required  DoDAAC  report  must  be  received  at  DLA.  DLA,  in  conjunction  with 
AFDSC,  will  edit  and  verify  to  the  maximum  extent  possible,  given  the  amount 
of  data  reported  and  the  frequency  of  the  reports.  In  most  instances,  this 
editing  will  consist  of  no  more  than  the  elimination  of  obvious  errors  from 
the  data  base  update  file.  After  editing,  accepted  data  will  be  loaded  into 
the  PEERS  data  base,  either  the  same  day  or  overnight.  (A  list  of  reporting 
errors  will  be  submitted  to  each  Service  energy  office.  These  offices  will 
take  appropriate  action  to  ensure  accurate  data  are  submitted  for  the  next 
reporting  period.)  After  the  data  base  update  is  complete,  the  PEERS  data  will 
be  available  for  ad  hoc  reports  and  queries.  The  AFDSC  will  advise  the  system 
operator  and  the  Energy  Office  of  any  machine  or  scheduling  problems  affecting 
this  schedule. 

4.1,3  Data  Base  Back-up  Procedures. 

A  back-up  of  the  PEERS  data  base  will  be  made  after  each  reporting  cycle 
update.  Thus,  if  reporting  is  weekly,  a  back-up  will  be  made  once  each  week. 
In  addition,  a  back-up  will  be  made  of  all  changes  to  the  data  base  since  the 
last  complete  data  base  back-up  so  that  the  PEERS  data  base  can  be  recreated 
if  necessary.  Only  the  most  current  back-up  will  be  saved.  Outdated  data 
will  be  archived  to  magnetic  tape  for  possible  later  analysis;  a  back-up  of 
this  tape  will  also  be  made.  The  archiving  of  outdated  data  will  use  relevant 
INQUIRE  capabilities  so  that  the  data  base  can  be  easily  recreated. 


4.1.4  Recovery  Procedures. 

Restart  and  recovery  procedures  will  conform  to  standard  AFDSC  proce¬ 
dures.  Transaction  logging,  retention  of  PEERS  data  tapes,  and  data  base 
back-up  will  permit  recovery  of  a  damaged  data  base.  AFDSC  will  develop 
recovery  actions  consistent  with  their  operating  procedures. 

4.1.5  Access  to  DEIS  Data. 

Occasionally,  data  contained  in  the  DEIS  data  bases  will  be  needed  for  ad 
hoc  reports.  INQUIRE  capabilities  can  be  used  to  access  DEIS  data  for  on-line 
retrieval  and  reporting. 

4.1.6  Data  Monitoring. 

The  Defense  Energy  Policy  Office  will  have  management  responsibility  for 
PEERS,  and  AFDSC  will  have  programming  responsibility.  DLA  will  manage  PEERS 
operations  through  the  PEERS  system  operator  at  DFSC-CB.  The  PEERS  system 
operator  will  be  authorized  direct  communication  with  all  reporting  activities 
to  request  late  reports  and  to  verify  reported  data.  DFSC-CB  will  also 
coordinate  with  AFDSC  any  changes  to  coded  or  tabular  information  in  the  data 
b*P5e  and  any  changes  concerning  authorized  users.  DFSC-CB  will  enter  data  on 
fuels  in  transit  and  work  with  the  Defense  Energy  Policy  Office  and  AFDSC  when 
changes  to  PEERS  are  anticipated. 

4.2  System  Logic  Flow. 

The  general  system  flow  of  PEERS  is  designed  to  provide  functions  to  pro¬ 
cess  and  access  energy  consumption  and  requirements  data  in  a  timely  manner. 
Figure  4-1  illustrates  the  logical  flow  of  the  system.  The  functions  numbered 
on  the  figure  refer  to  the  section  of  this  document  describing  that  function. 

Data  will  enter  PEERS  through  AUTODIN,  the  DD173  message  form,  or  other 
communications  media.  The  data  will  be  collected  at  DLA,  Cameron  Station,  and 
PEERS  data  will  be  separated  from  other  data  and  recorded  on  magnetic  tape. 


The  PEERS  data  will  then  be  transmitted  to  AFDSC  for  further  processing. 


At  AFDSC,  PEERS  data  will  be  edited  for  format  and  validity  (compared  to 
data  already  in  the  data  base).  Records  believed  to  be  in  error  will  be 
placed  on  the  Rejection  File  for  review.  Records  with  a  date  older  than  the 
specified  cut-off  date  will  also  be  placed  on  the  Rejection  File.  Those 
activities  which  have  not  submitted  PEERS  data  will  be  identified  and 
reported.  Data  which  pass  these  edits  will  be  converted  to  the  INQUIRE  data 
base  format,  and  the  data  base  will  be  updated. 

If  time  permits,  erroneous  data  records  will  be  corrected  and  resubmitted 
for  editing,  conversion,  and  data  base  updating.  Data  relating  to  installa¬ 
tions,  such  as  the  name  and  address,  product  names,  and  conversion  factors, 
are  maintained  on  an  INQUIRE  coded  information  file.  These  header  files  are 
processed  and  updated  through  DEIS. 

PEERS  reports  will  be  specifically  tailored  to  a  particular  energy  emer¬ 
gency.  Users  will  develop  ad  hoc  reports  and  queries  as  needed  and  obtain  them 
directly  from  the  computer  once  the  PEERS  data  become  available.  Errors  in 
reports  detected  by  the  data  submitters  can  be  corrected  via  AUTODIN  or  the 
system  operator  (if  time  permits). 

The  data  base  will  contain  energy  data  for  DoDAAC  product  usage  for  the 
most  recent  five  to  nine  weeks.  Five  weeks  of  PEERS  data  will  provide  a  one- 
week  overlap  of  DEIS-I  data;  nine  weeks  of  PEERS  data  will  provide  a  one-week 
overlap  of  DEIS-II  data.  Any  consumption  data  required  for  an  earlier  period 
can  be  obtained  from  DEIS  files.  Out-of-date  data  will  be  removed  from  the 
on-line  PEERS  data  base  as  time  permits  and  stored  off-line  on  magnetic  tape. 
These  tapes  will  be  saved  for  possible  analysis  at  a  later  date. 

4,3  System  Data. 


This  subsection  briefly  describes  the  inputs,  outputs,  and  data  base  to  be 
used  in  PEERS.  Additional  detail  on  these  items  is  provided  in  Section  4.4. 


Inputs  to  PEERS  will  consist  of  input  data  card  images  submitted  by 
reporting  DoDAACS  and  header  record  information  obtained  from  the  DEIS  MEA1 
and  MEB1  files.  Appendix  B  provides  the  formats  of  the  data  cards.  A 
description  of  the  data  elements,  source,  format,  and  acceptable  values  is 
contained  in  Appendix  A.  Data  cards  will  be  submitted  by  the  required 
reporting  activities  according  to  the  emergency  schedule  specified  by  the 
Defense  Energy  Policy  Office  in  conjunction  with  the  Services. 

The  PEERS  header  file  information  on  each  reporting  DoDAAC  will  be 
obtained  from  the  DEIS  I  and  DEIS  II  header  files.  The  records  in  this  header 
file  provide  additional  information  on  each  reporting  DoDAAC  such  as  installa¬ 
tion  name,  region,  state,  major  command,  etc.  Appendix  A  provides  definitions 
of  these  header  file  data  elements.  The  coded  information  items  contained  in 
these  files  will  be  submitted  and  maintained  through  DEIS. 

4.3.2  Outputs . 

The  following  is  a  list  of  the  reports  to  be  generated  by  PEERS.  More 
detail  on  the  report  formats  is  contained  in  the  descriptions  of  the 
functions . 

-  Transaction  Proof  Listing 

-  PEERS  Activities  Not  Reporting 

-  PEERS  Activities  Reporting  Changes 

-  Ad  Hoc  Reports. 

4.3.3  Data  Base. 

The  PEERS  data  base  will  be  constructed  using  the  INQUIRE  DBMS. 
Figure  4-2  shows  a  schema  of  the  data  base.  The  size  of  this  on-line  data 


base  will  depend  on  the  extent  of  the  DoDAAC  and  product  reporting  required 
for  PEERS.  In  a  worst-case  scenario  of  a  national  emergency,  with  all  DEIS 


products  being  reported,  the  on-line  data  base  would  contain  (not  including 
any  overhead)  approximately  392,000  records  of  154  characters. 


FIGURE  4-2.  PEERS  DATA  BASE  SCHEMA 
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4.4  System  Program  Descriptions. 

The  PEERS  programs  are  described  in  the  following  paragraphs.  These 
functions  are  presented  in  the  sequence  in  which  they  will  typically  be  used 
during  a  PEERS  reporting  cycle. 

4.4.1  Generate  PEERS  Header  File. 

This  function  will  produce  a  PEERS  header  file  similar  to  the  DEIS-I  MEA1 
file  and  the  DEIS-II  MEB1  file. 
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4.4. 1.1  Purpose. 

The  data  base  design  for  PEERS  is  similar  to  that  of  DEIS  in  that  the 
data  will  be  separated  into  two  distinct  files: 

-  A  header  file  containing  the  data  elements  describing  the  reporting 
installations.  These  data  include  such  information  as  the  installa¬ 
tion  name  and  location,  Service  and  major  command  to  which  the 
activity  is  assigned,  etc.  These  data  are  relatively  static  and  are 
already  maintained  and  updated  through  the  DEIS  system. 

-  A  product  file  containing  the  consumption  and  requirements  information 
for  each  DoDAAC  and  energy  product  from  each  PEERS  report. 

Separating  the  data  into  two  files  will  reduce  storage  requirements  and 
improve  the  performance  of  PEERS.  The  header  data  are  already  updated  and 
maintained  under  DEIS;  consequently,  the  PEERS  header  file  can  be  generated 
from  the  DEIS  header  files  by  extracting  the  header  records  for  only  those 
DoDAACs  required  to  report  for  PEERS.  The  Generate  PEERS  Header  File  function 
will  extract  header  information  for  the  appropriate  installations  from  either 


the  DEIS  MEA1  or  MEB1  files. 


4. 4. 1.2  Data  Definition. 


The  data  elements  to  be  used  in  the  Generate  PEERS  Header  File  function 
are  shown  in  Appendix  A.  The  data  definitions  are  identical  to  those  of  DEIS. 

4.4. 1.3  Processing  Logic. 

The  Generate  PEERS  Header  File  function  will  use  INQUIRE  query  capabili¬ 
ties  to  extract  records  from  the  MEA1  and  MEB1  files  and  generate  a  data  base 
containing  a  record  for  each  DoDAAC  required  to  report  for  PEERS.  This  query 
may  consist  of  a  list  of  DoDAACs  or  a  description  of  the  DoDAACs  to  be 
extracted,  e.g.,  all  Air  Force  installations  in  California.  Figure  4-3 
details  the  major  processing  steps  to  produce  this  MEC1  file.  Some  DoDAACs 
are  contained  in  one  DEIS  header  file  and  not  in  the  other;  hence,  the  query 
will  have  to  search  both  files  until  the  DoDAAC  record  is  found. 


The  output  of  the  Generate  PEERS  Header  File  function  will  be  a  MEC1  file 
containing  the  header  record  information  for  each  installation  required  to 
report  under  PEERS.  This  file  will  be  identical  in  format  to  the  MEA1  and 
MEB1  files. 

4.4.2  Edit  and  Convert  Data. 

This  function  will  sort  the  PEERS  input  data  cards,  test  numeric  fields, 
check  whether  the  data  were  previously  edited,  check  the  data  for  reasonable¬ 
ness,  and  convert  the  data  to  the  format  required  to  update  the  data  base. 

4.4.2. 1  Purpose. 

The  purpose  of  the  Edit  and  Convert  Data  function  is  to  edit/validate 
PEERS  product  information,  to  produce  the  Transaction  Proof  Listing  of  those 
records  which  fail  the  edit  criteria,  and  to  format  the  data  for  updating  the 
data  base. 

4 .4. 2. 2  Data  Definition. 

The  data  items  required  for  the  Data  Edit  and  Conversion  function  are 
described  in  more  detail  in  Appendix  A.  In  this  section,  when  the  words 
"product  record"  appear,  they  mean  all  the  data  contained  on  the  MEC-2/3  input 
cards  in  either  card  image  format  or  another  format. 

4. 4. 2. 3  Processing  Logic. 

Figure  4-4  is  a  flowchart  of  the  major  processing  steps  in  the  Data  Edit 
and  Conversion  function.  The  first  step  in  the  conversion  process  will  be  to 
sort  the  PEERS  input  data  cards  to  allow  more  efficient  updating  of  the  data 
base  and  editing  of  the  data.  The  following  data  will  be  used  in  the  listed 
sequence  as  sort  keys: 


DoDAAC 

Reporting  Date 
Product  Code 


I*. 


FIGURE  4-4.  PEERS  EDIT  AND  CONVERT  DATA 
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-  Card  Number 

-  Remarks  Number. 

Next,  these  sorted  records  will  be  processed  through  a  series  of  edit 
steps  which  produce  accepted  and  rejected  files  and  various  error  reports. 
The  following  subsections  describe  the  edit  criteria. 

4. 4. 2. 3.1  Common  Data  Edits. 

Due  to  transmission  errors,  the  data  may  be  offset  by  one  column.  Some 
of  these  errors  are  recoverable.  If  the  blank  is  missing  or  there  are  two 
blanks  between 

-  MEC  (Card  Type)  and  Card  Number, 

-  Card  Number  and  DoDAAC, 

-  DoDAAC  and  Reporting  Date,  or 

-  Reporting  Date  and  Product  Code, 

the  blank  space  will  be  inserted  (or  deleted)  and  the  edit  process  will  con¬ 
tinue.  These  card  images  will  be  printed  as  they  were  submitted  on  the  Trans¬ 
action  Proof  Listing  with  a  message  that  a  space  was  inserted  (deleted)  and 
the  position  (card  column)  where  the  change  was  made.  Misalignment  in  other 
fields  of  the  input  record  is  not  recoverable.  The  error  message  for  these 
records  will  indicate  that  the  blank  field  is  filled  (and  the  card  column)  at 
the  misalignment. 

Three  data  elements  are  common  to  the  MEC-2/MEC-3  data  formats:  DoDAAC, 
Date,  and  Product  Code.  Validation  of  these  three  elements  will  be  as 
follows : 

-  The  DoDAAC  of  the  MEC-2/3  input  must  match  a  DoDAAC  in  the  data  base. 
(Before  this  validation  occurs,  all  DoDAACs  beginning  with  R  or  V 
(vessels)  must  first  be  converted  to  N  for  comparison  purposes.)  If 
the  DoDAACs  do  not  match,  the  record  must  be  indicated  with  an  error 
message  on  the  Transaction  Proof  Listing. 

-  The  date  of  a  MEC-2/3  input  must  be  less  than  or  equal  to  the  date  of 
the  period  being  reported.  To  facilitate  this  validation,  the  correct 
date  may  be  submitted  on  a  PARM  card.  If  the  input  date  is  older  than 


the  specified  cut-off  date,  the  record  should  be  printed  with  an  error 
message  indicating  that  the  change  is  out-of-date  and  placed  on  the 
Rejection  File.  If  the  input  date  is  ahead  of  the  correct  date,  the 
area  message  should  indicate  an  invalid  date. 

-  The  Product  Code  on  a  MEC-2/3  card  must  match  acceptable/valid  product 
codes  established  on  the  coded  information  portion  of  the  data  base. 
Before  this  match  is  made,  however,  the  following  conversion  should  be 
accomplished.  If  the  Product  Code  on  the  MEC-2/3  card  is  NFD,  convert 
it  to  NDF.  If  the  Product  Code  is  NFS,  convert  it  to  NSF.  If  the 
Product  Code  is  DFZ,  convert  it  to  DF2.  If  the  Product  Code  is  JPS, 
convert  it  to  JP5.  If  there  is  a  hyphen  in  the  Product  Code,  remove 
it  and  shift  the  subsequent  fields  before  the  misalignment  of  the 
fields  is  checked. 

If,  after  the  above  conversion  and  a  match  with  valid  product  codes,  the 
Product  Code  on  the  input  is  not  valid,  print  the  record  on  the  Transaction 
Proof  Listing  with  a  message  such  as  INVALID  PRODUCT  CODE  and  place  the  record 
on  the  Rejection  File. 

4. 4. 2. 3. 2  MEC-Specific  Edits. 

If  the  Closing  Inventory  and  Issues  fields  are  more  than  20  percent 
larger  or  smaller  than  the  Closing  Inventory  and  Issues  fields  of  the  prior 
reporting  period,  a  message  to  that  effect  will  be  printed  on  the  Transaction 
Proof  Listing.  The  MEC-2  card  image  and  the  values  from  the  prior  period  also 
.will  be  printed. 

Each  retail  activity  reporting  will  submit  a  MEC-2,  and  possibly  two 
MEC-3  cards  for  each  product  reported.  If  the  card  has  the  same  Reporting 
Date,  DoDAAC,  and  Product  Code  as  a  record  on  the  data  base  for  a  prior 
period,  it  will  be  treated  as  a  change  (see  Section  4. 4. 2. 3. 3  below). 
Accepted  transactions  will  be  listed  as  discussed  in  4. 4. 2. 4.  Validation  of 
other  data  on  the  MEC-2/3  input  is  summarized  in  Table  4-2. 

Every  transaction  will  be  checked  for  duplication  of  either  previous 
reported  data  in  the  current  reporting  cycle  or  duplication  of  a  data  base 
record  (a  change  transaction).  If  the  record  duplicates  a  record  type, 


DoDAAC,  Product  Code,  and  Reporting  Date  of  a  record  in  the  current  cycle 


TABLE  4-2.  DATA  EDIT  ITEMS 


Card  Data  Element 

Card  Column 

Validity  Checks 

MEC-2 

22 

Blank  | 

Closing  Inventory 

22-30 

Numeric,  non-negative,  within  ■ 

20%  of  prior  week  inventory  { 

31 

Blank 

Issues 

32-39 

Numeric,  non-negative,  within  1 

20%  of  prior  week  issues 

40 

Blank 

Anticipated  Issues 

41-48 

Numeric,  non-negative 

49 

Blank 

Anticipated  Receipts 

50-57 

Numeric,  non-negative 

58-79 

Not  used  by  PEERS 

Action  Code 

80 

Blank,  C(change),  or  j 

D(delete)  i 

i 

MEC-3 

22 

Blank 

Remarks  Number 

23 

Blank,  1,  or  2 

Remarks 

24-78 

79 

Blank 

Action  Code 

_ 

80 

Blank,  C,  or  D 

update,  an  error  message  indicating  DUPLICATE  should  be  reflected.  If  all 
80  columns  are  duplicated,  the  second  record  should  be  ignored.  Change  trans¬ 
actions  are  discussed  in  Section  4. 4. 2. 3. 3. 

If  a  record  entered  as  a  change  matches  a  record  on  the  data  base  exactly 
(all  80  columns),  ignore  the  new  record  and  print  no  error  message.  If  an  add 
transaction  being  input  matches  a  record  on  the  data  base  on  DoDAAC,  Product 
Code,  and  Reporting  Date,  print  an  error  message  DUPLICATE.  Print  this 
product  record  error  together  with  the  master  record.  Identify  the  master 
record  on  the  listing  with  a  FROM  DATA  BASE  message.  Place  the  input  product 
record  on  the  Rejection  File.  Section  4. 4. 2. 3. 3  will  expand  further  on  these 
"changes". 
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All  numeric  quantity  fields  on  the  MEC-2/3  will  be  validated.  If  the 
field  is  not  numeric,  print  the  product  record  with  a  message  such  as  FIELD 


MOT  NUMERIC. 

All  product  records  in  error  will  be  printed  on  the  Transaction  Proof 
Listing  and  written  on  the  Error  File.  Product  records  containing  an  error 
will  update  the  data  base  if  they  have  been  previously  edited  and  contain  an 
"E"  in  column  79  (see  on-line  correction  function) .  The  MEC-2/3  data  will  be 
printed  for  each  product  record  in  error. 

4. 4. 2. 3. 3  Change  Transaction  Edits. 

Change  transactions  (a  matching  record  in  the  data  base  for  a  previous 
reporting  period)  may  be  submitted  from  the  field  activities  or  by  the  system 
operator.  These  transactions  must  match  a  record  in  the  data  base  on  DoDAAC, 
Product  Code,  and  Date.  If  no  match  is  found,  print  a  message  beside  the 
transaction  on  the  Transaction  Proof  Listing  stating  UNMATCHED.  The  entire 
contents  of  a  card  will  be  submitted  for  a  change  of  a  field  on  that  card. 

New  zero  entries  will  replace  existing  entries  provided  they  pass  the 
edits.  A  set  (MEC-2/3)  is  not  necessary  for  a  change  transaction.  If  the 
change  matches  a  data  base  record,  overlay  the  old  data  with  the  new  data. 
This  overlay  will  not,  however,  be  accomplished  before  all  of  the  validation 
identified  for  an  add  transaction  is  performed.  If  the  change  data  fail  the 
edits,  reject  the  new  data,  print  the  data  as  an  error  on  the  Transaction 
Proof  Listing,  and  place  it  on  the  Rejection  File. 

4. 4. 2. 3. 4  Delete  Transaction  Edits. 

Delete  transactions  (CC  1-5  =  MEC-2  and  CC  80  =  D)  must  match  on  the 
DoDAAC,  Date,  and  Product  Code.  If  an  exact  match  does  not  occur,  print  the 
transaction  on  the  Transaction  Proof  Listing  with  a  message  such  as  UNMATCHED 
and  place  the  transaction  on  the  Rejection  File.  If  there  is  an  exact  match, 


delete  the  master  record.  Beside  the  transaction  on  the  Transaction  Proof 
Listing,  print  MASTER  DELETED  and  the  data  which  were  deleted. 

4. 4. 2. 3. 5  Non-Reporting  Activities  Edits. 

Those  activities  (DoDAACs)  in  the  data  base  for  which  no  data  (no  MEC 
cards)  were  received  should  be  printed  on  the  PEERS  Activities  Not  Reporting 
listing.  A  listing  will  also  be  provided  showing  the  activities  not  reporting 
the  same  products  reported  in  the  previous  cycles. 

The  listings  will  indicate  the  Region  Code,  State/Country  Code,  Installa¬ 
tion  Name,  Major  Command,  and  Service/Agency  Code  for  each  DoDAAC.  These  data 
will  be  taken  from  the  coded  information  file. 

For  those  activities  reporting  changes  in  products  used,  the  Product  Code 
will  be  determined  as  follows:  if  no  (MEC-2)  data  are  submitted  for  a  Product 
Code  reported  on  the  previous  report,  reflect  this  unreported  product  along 
with  the  anticipated  receipts  of  the  previous  report. 

4. 4. 2. 3. 6  Conversion. 

Data  will  be  converted  from  MEC  card  format  to  the  format  required  for 
INQUIRE  data  base  updating. 

4. 4. 2. 4  Outputs. 

There  will  be  seven  outputs  from  the  Edit  and  Convert  Data  function: 

-  Records  which  have  passed  the  data  edits  and  are  converted  to  INQUIRE 
data  base  update  format  will  update  the  data  base.  As  many  as 
2000  records  (MEC-2/3  combination)  may  pass  the  data  edits  at  one 
time. 

-  Records  which  have  passed  the  data  edits  will  be  printed  on  the 
Accepted  Records  Listing  in  DoDAAC  order  within  each  Service.  A 
sample  of  this  report  layout  is  given  in  Figure  4-5. 

-  Records  which  fail  the  data  edits  will  be  written  on  the  Rejection 
File.  As  many  as  1000  records  may  fail  the  data  edits  at  one  time. 
Because  of  this  volume,  this  file  should  be  arranged  for  selective  as 
well  as  sequential  access. 


Records  which  fail  the  data  edits  will  be  printed  on  the  Transaction 
Proof  Listing  in  DoDAAC  order  within  each  Service.  This  listing  will 
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contain  the  images  of  the  records  on  the  Rejection  File  and  the  appro¬ 
priate  error  messages  (specified  in  4. 4. 2. 3).  Multiple  error  messages 
may  be  printed.  A  sample  of  this  report  layout  is  also  given  in 
Figure  4-5.  A  listing  for  each  Service  will  be  sent  to  each  Service 
energy  office.  The  Service  energy  office  will  be  responsible  for 
taking  action  to  ensure  the  accuracy  of  submissions  for  the  next 
reporting  cycle. 

-  Activities  which  did  not  submit  data  will  be  reported  on  the  PEERS 

Activities  Not  Reporting  listing.  Page  breaks  are  needed  only  when 

the  print  limitation  of  the  page  is  reached.  The  total  number  of 

activities  not  reporting,  by  MEC  type,  will  be  printed  at  the  end  of 

the  report.  A  sample  of  this  report  layout  is  given  in  Figure  4-6. 

-  PEERS  Error  Statistics  giving  the  number  of  times  each  error  message 
is  printed  will  be  printed  at  the  end  of  each  edit  rim.  This  listing 
will  be  sent  to  the  system  operator.  A  sample  of  this  report  layout 
is  given  in  Figure  4-7. 

4.4.3  Update  Data  Base. 

This  function  will  be  performed  mainly  through  the  generalized  DBMS  capa¬ 
bilities  and  will  provide  for  applying  records  with  correct  data  to  the  data 
base.  The  data  base  update  will  occur  at  least  once  each  reporting  cycle. 
Since  there  will  be  very  little  time  to  correct  errors  and  add  late  reporters, 
the  update  will  probably  occur  no  more  than  twice  each  reporting  cycle. 

4.4.3. 1  Purpose. 

The  purpose  of  the  Update  Data  Base  function  is  to  add,  change,  and 
delete  data  in  the  product  data  base.  This  includes  the  ability  to  add  new 
data  fields  or  delete  existing  ones  by  reorganizing  the  data  base.  Fields 
will  be  added  or  deleted  infrequently  and  only  after  consultation  with  AFDSC. 
Records  with  data  items  found  to  be  in  error  during  the  update  will  be  placed 
on  the  Rejection  File,  for  on-line  editing  of  the  error  records  (if  time 
permits) . 

4. 4. 3. 2  Data  Definition. 

The  data  items  input  to  the  Update  Data  Base  function  are  shown  in 


Table  4-3.  A  more  detailed  description  of  each  data  item  can  be  found  in 
Appendix  A. 


FIGURE 


TABLE  4-3.  DATA  BASE  UPDATE  DATA  ITEMS 


Data  Element 
Name 

1 

Comments 

DODAAC 

DoD  Activity  Address  Code 

RPTDATE 

Reporting  Date  (Month,  Day) 

PRODCODE 

Product  Code 

ISSUES 

Total  Issues/Consumption 

AISSUES 

Anticipated  Issues/Consumption 

ARECPTS 

Anticipated  Receipts 

DAYSUP 

Days  of  Supply 

DTEUP 

Date  of  Update 

CORRECT 

Correction  Code 

4. 4. 3. 3  Processing  Logic. 

Those  records  that  passed  the  edits  described  in  4.4.2  will  be  applied  to 
the  PEERS  data  base.  In  addition,  Days  of  Supply  will  be  calculated  as 
follows:  Days  of  Supply  =  Inventory  v  Anticipated  Consumption  r  Number  of 

Days  in  the  Reporting  Cycle.  Days  of  Supply  will  be  truncated  to  a  whole 
number,  that  is,  if  the  calculation  yields  4.9  days  of  supply,  4  will  be 
placed  in  the  data  base.  The  input  records  will  be  saved  as  a  transaction 

log.  Any  data  rejected  by  INQUIRE  at  this  stage  will  also  be  placed  on  the 

Rejection  File  for  subsequent  data  correction  if  possible. 

4 . 4 ■ 3 . 4  Output . 

The  outputs  of  the  Update  Data  Base  function  will  be  an  updated  PEERS 
data  base  and  the  Rejection  File.  The  data  to  be  written  on  the  Rejection 

File  will  be  converted  to  MEC  card  image  format  for  ease  of  user  correction. 

4.4,4  Generate  Ad  Hoc  Reports. 

This  function  will  provide  macros  to  extract  data  from  the  PEERS  data 

base. 

4.4.4. 1  Purpose. 

Reporting  flexibility  is  a  key  requirement  of  an  emergency  information 
system.  The  INQUIRE  DBMS  provides  the  analytical  capabilities  to  allow,  on 


very  short  notice,  the  development  of  reports  tailored  to  a  specific  emer¬ 
gency.  These  ad  hoc  reports  will  be  used  to  assess  the  severity  of  energy 
shortages,  provide  feedback  on  energy  conservation  efforts,  and  answer  Con¬ 
gressional  and  Department  of  Energy  information  requests.  Figure  4-8  provides 
a  sample  of  the  type  of  ad  hoc  reports  which  can  be  easily  produced  using  the 
INQUIRE  query  capabilities. 

4. 4. 4. 2  Data  Definition. 

All  fields  contained  in  the  data  base  (see  Appendix  A)  may  be  used  in 
producing  the  reports . 

4. 4. 4. 3  Processing  Logic. 

The  queries  to  generate  the  ad  hoc  reports  will  simply  retrieve  certain 
data  elements,  based  on  user-specified  selection  criteria,  and  display  the 
data.  At  times,  simple  arithmetic  operations  on  the  data  may  be  requested. 
The  macros  will  assign  any  required  files,  invoke  the  appropriate  processors, 
and  assist  the  user  in  creating  and  saving  the  query  statements. 

4 . 4 . 4 . 4  Output . 

Output  will  be  printed  on  the  originating  terminal,  directed  to  another 
(high-speed)  printer,  or  saved  in  a  file  for  further  processing.  At  the 
user's  option,  the  statements  used  to  generate  the  query  may  be  saved  for 
future  use  and  modification. 

4.4.5  Delete  Outdated  Data. 

After  the  time-sensitive  processing  of  PEERS  data  is  complete,  data  base 
maintenance  will  be  performed  by  deleting  outdated  data.  Records  will  be 
deleted  from  the  on-line  data  base  when  their  reporting  date  is  older  than  the 
most  current  DEIS  report.  Depending  on  the  time  of  the  month  and  products 
reported,  the  PEERS  on-line  data  base  could  include  as  many  as  five  to  nine 
weeks  of  PEERS  reports.  The  deleted  PEERS  records  will  be  archived  on 


magnetic  tape. 


FIGURE  4-8 .  SAMPLE  AD  HOC  REPORTS 

For  OSD 


For  Services 


U.S.  AMT 

CQMUHD  STATUS  REPORT 
PURL  OIL 


MAJOR  DATS  OP  ANTICIPATED  ANTICIPATED 

command  nmarrosT  supply  issues  receipts 


DARCOM 
TORS COM 

traooc 


TOTALS 


For  Service  Control  Points 


USAP 

MIDWEST  STATES 
NATURAL  GAS 


PRIOR  DATS  OP  ANTICIPATED  ANTICIPATED 

INSTALLATION  CONSUMPTION  SUPPLY  ISSUES  RECEIPTS  REMARKS 


Illinois  Chanties  AFB 

Scott  AFB 
O' Haro 

Indiana  Grlsson  APR 


Michigan  K.t.  Savyar  APB 
Uurtaaleh  APR 


Mlnnaaota  Mlnnaapolia  AP 


This  deletion  process  provides  a  method  for  minimizing  processing  time 
and  data  storage  requirements.  Only  PEERS  reports  since  the  date  of  the  last 
complete  DEIS  report  will  be  needed  in  the  PEERS  data  base;  DEIS  would  provide 
the  inventory  and  consumption  data  previous  to  that  date,  and  anticipated 
consumption  and  receipts  are  needed  only  from  the  most  recent  PEERS  report. 
The  most  recent  PEERS  report  will  always  be  retained  in  the  on-line  data  base. 

Data  deleted  from  the  PEERS  product  data  base  will  be  archived  on 
magnetic  tape  in  a  format  that  allows  easy  creation  of  a  data  base  for  a 
specified  time  period.  These  historical  data  will  provide  a  means  for  assess¬ 
ing  the  accuracy,  validity,  and  completeness  of  PEERS  data  at  some  later  date 
and  possibly  suggest  methods  for  improving  PEERS  procedures.  This  function 
will  also  supplement  AFDSC  procedures  to  back-up  the  on-line  data  base. 

4. 4. 5.2  Data  Definition. 

PEERS  data  items  used  in  the  Delete  Outdated  Data  function  will  include 
the  reporting  date  (for  selection  purposes)  and  all  data  elements  in  the 
product  data  base.  The  data  of  the  most  recent  DEIS  and  PEERS  reports  will 
also  be  needed.  The  PEERS  data  items  are  described  in  Appendix  A. 

4. 4. 5. 3  Processing  Logic. 

The  procedure  for  the  Delete  Outdated  Data  function  will  consist  of  a 
simple  scan  of  the  PEERS  product  base  comparing  the  reporting  date  of  each 
record  to  the  oldest  of  either  the  most  recent  DEIS  or  PEERS  reports.  Records 
older  than  this  date  will  be  copied  to  archival  storage  and  deleted  from  the 
on-line  data  base;  the  remaining  records  will  be  retained  in  the  on-line  data 
base.  Figure  4-9  shows  the  major  processing  steps  of  this  function. 

4. 4. 5. 4.  Outputs. 


The  outputs  of  the  Delete  Outdated  Data  function  will  be  an  updated  PEERS 
product  data  base  and  an  INQUIRE-format  archival  file  of  the  records  purged. 
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APPENDIX  A 


DATA  DICTIONARY 

This  description  of  PEERS  data  items  is  separated  into  two  categories, 
product  data  and  header  data.  These  data  are  maintained  in  two  separate 
files .  Product  data  are  defined  as  the  information  submitted  by  reporting  DoD 
activities  on  the  MEC-2/3  cards  (see  Appendix  B  for  formats  of  these  cards). 
These  data  are  submitted  with  each  reporting  period  and  contain  the  inventory 
and  consumption  data  for  each  energy  product.  The  header  data  consist  of 
those  data  elements  which  describe  a  DoD  activity  such  as  installation  name, 
region,  major  command,  Service,  etc.  These  data  elements  are  identical  with 
the  header  data  contained  in  DEIS-I  MEA1  and  DEIS-II  MEB1  files. 

Within  each  category,  the  elements  are  listed  in  alphabetical  order.  The 
format  type,  length  (number  of  characters),  source,  number  of  occurrences, 
frequency  of  update  or  submission,  definition,  and  edit  criteria  are  given  for 
each  data  element.  The  product  data  are  shown  in  Table  A-l.  The  header  data 
are  shown  in  Table  A-2. 


APPENDIX  B 

DATA  COLLECTION  CARD  FORMATS 

This  appendix  contains  the  card  layouts  for  the  PEERS  input  data  card(s) 
submitted  by  the  reporting  activities.  A  MEC-2  input  card  is  submitted  for 
each  product  for  which  reporting  is  required.  Up  to  two  MEC-3  cards, 
containing  the  optional  REMARKS  data  element  field,  may  be  submitted  along 
with  each  MEC-2  card. 


TABLE  B-l 

PEERS  -  MEC-2  CARD  LAYOUT 


Field 

Length 

Card 

Column 

Data  Description 

3 

1-3 

Card  Type  (MEC) 

1 

4-4 

Blank 

1 

!  5-5 

Card  Number  (2) 

1 

6-6 

Blank 

6 

7  -  12 

DoDAAC 

1 

13  -  13 

Blank 

2 

14  -  15 

Reporting  Date  (Month) 

2 

16  -  17 

Reporting  Date  (Day) 

1 

18  -  18 

Blank 

3 

12  -  21 

Product  Code 

1 

22  -  22 

Blank 

8 

23-30 

Closing  Inventory 

1 

31  -  31 

Blank 

8 

32  -  39 

Total  Issues/Consumption 

1 

40  -  40 

Blank 

8 

41  -  48 

Anticipated  Issues 

1 

42  -  49 

Blank 

8 

50  -  57 

Anticipated  Receipts 

23 

58  -  80 

Blank 

TABLE  B-2 


PEERS  -  MEC-3  CARD  LAYOUT 


Field 

Length 


Card 

Column 


Data  Description 


3 
1 
1 
1 
0 
1 

4 
2 
1 

3 
1 
1 

55 

4 


1  -  3 

4- 4 

5- 5 

6- 6 
7-12 

13  -  13 

14  -  15 
16  -  17 
18  -  18 
19  -  21 
22  -  22 

23  -  23 

24  -  78 
79  -  80 


Card  Type  (MEC) 
Blank 

Card  Number  (3) 


Blank 

DoDAAC 

Blank 


Reporting  Date  (Month) 
Reporting  Date  (Day) 
Blank 

Product  Code 
Blank 

Remarks  Number 

Remarks 

Blank 


it  nnmm  tv  /i 


TABLE  C-2 


REGION/ STATE/ COUNTRY  CODES1 


REGION/CINC 

REGION  CODE 

STATE/COUNTRY 

CODE 

REGION  1 

01 

ConnecClcuC 

01 

09 

Maine 

01 

23 

Massachuseccs 

01 

25 

New  Hampshire 

01 

33 

Vermont 

01 

50 

Rhode  Island 

01 

44 

REGION  2 

02 

New  Jersey 

02 

34 

New  York 

02 

36 

REGION  3 

03 

Delaware 

03 

10 

Districc  of  Columbia 

03 

11 

Maryland 

03 

24 

Pennsylvania 

03 

42 

Virginia 

03 

51 

Wesc  Virginia 

03 

54 

REGION  4 

04 

Alabama 

04 

01 

Florida 

04 

12 

Georgia 

04 

13 

KenCucky 

04 

21 

Mississippi 

04 

28 

Norch  Carolina 

04 

37 

Souch  Carolina 

04 

45 

Tennessee 

04 

47 

REGION  3 

05 

Illinois 

05 

17 

Indiana 

05 

18 

Michigan 

05 

26 

Minnesoca 

05 

27 

Ohio 

05 

39 

Wisconsin 

05 

55 

^Th*  region  Cable  will  have  Che  region  code  and  Che  region/CINC  name. 
The  scace  cable  will  have  Che  scace  code,  Che  region  code  and  che 

scace  name. 


C-3 


TABLE  C-2  (Cont.) 


REGION/ CINC 

REGION  CODE 

REGION  6 

06 

Arkansas 

06 

Louisiana 

06 

New  Mexico 

06 

Oklahoma 

06 

Texas 

06 

REGION  7 

07 

Iowa 

07 

Kansas 

07 

Missouri 

07 

Nebraska 

07 

REGION  8 

08 

Colorado 

08 

Montana 

08 

North  Dakota 

08 

South  Dakota 

08 

Utah 

08 

Wyoming 

08 

REGION  9 

09 

Arizona 

09 

California 

09 

Nevada 

09 

REGION  10 

10 

Idaho 

10 

Oregon 

10 

Washington 

10 

CINCs2 

CANADA  &  GREENLAND 

Western  Canada 

3X 

Argentia,  Eastern  Canada 

3D 

Greenland 

3E 

CINCAL 

Alaska 

1A 

Aleutian  Islands 

IB 

^When  multiple  codes  appear  in  a  CINC,  each  code  vlll  have  ics  own 
region  name. 


TABLE  C-2  (Cont.) 


REGION /CINC 

REGION  CODE 

STATE /COUNTRY 
CODE 

CINCSOU 

• 

Canal  Zone 

6A 

PQ 

Easter  Island  (Chile) 

6A 

Cl 

CINCEUR 

• 

Belgium 

4K 

BE 

Crete  (Greece) 

4Q 

GR 

Cyprus 

4Q 

CY 

Denmark 

4K 

DA 

France 

4M 

FR 

Germany 

4K 

GE 

Italy 

4P 

IT 

Malta 

4S 

MT 

Morocco 

4R 

MO 

Netherlands 

4K 

NL 

Norway 

4J 

NO 

Sardinia 

4P 

SD 

Sicily 

4P 

SI 

Spain 

4N 

SP 

Portugal 

4N 

PO 

Turkey 

4Q 

TU 

United  Kingdom  (Great  Britain 

4L 

UK 

&  Northern  Ireland,  including 
Channel  Islands) 

MISCELLANEOUS 

Ceylon 

7F 

CE 

Egypt 

7C 

EG 

Eritrea  (Ethiopia) 

7C 

ET 

Kenya 

7C 

KE 

Lebanon 

7D 

LE 

Saudi  Arabia 

7D 

SA 

CINCLANT 

Ascension  Island 

2R 

SG 

Azores 

2K 

AZ 

Bermuda 

2D 

BD 

Cuba 

2C 

CU 

Haiti 

2C 

HA 

Iceland 

2H 

IC 

Puerto  Rico 

2C 

RQ 

Virgin  Islands 

2C 

VQ 

West  Indies — includes 

Leeward  Islands 

2C 

LW 

Windward  Islands 

2C 

WI 

Jamaica 

2C 

JM 

Dominican  Republic 

2C 

DR 

Netherlands  West  Indies 

2C 

NA 

Trinidad 

2C 

TD 

TABLE  02  (Cont.) 


REGION /CINC 

REGION  CODE 

1 

STATE/COUNTRY ! 
CODE  ! 

CINCPAC 

1 

Australia 

5E 

AS 

Diego  Garcia 

5S 

MR 

Hawaii 

5N 

15 

Japan 

5H 

JA 

Johnston  Island 

5N 

JQ 

Korea 

5H 

KS 

Laos 

5D 

LA 

Marianas  Islands 

5G 

MS 

Marshall  Islands  (Pacific  Islands) 

5B 

TQ 

Midway  Island 

5N 

MQ 

New  Zealand 

5V 

NZ 

Philippines 

5C 

RP 

Ryukyu  Islands 

5H 

YQ 

Samoa  Islands 

5F 

AQ 

Taiwan 

5C 

TW 

Volcano  Islands 

5G 

BJ 

Wake  Island 

5F 

WQ 

South  Vietnam 

5D 

VS 

Thailand 

5D 

TH 

Malaysia 

5D 

MY 

Singapore 

5D 

SN 

VESSELS 

98 

98 

A  H 


fclALmUAilirUtfcilj 


TABLE  03- 


SERVICE/AGENCY  CODES 


Translation* 


Army 


Army  National  Guard 


Air  Force 


Air  National  Guard 


Navy 


Marine  Corps 


DFSC 


Other  DoD  Agencies 


IWhen  summarizing  Army,  Include  both  "A"  and  "B" 

When  summarizing  Air  Force,  include  both  ”F"  and  ”H" 


TABLE  C-4 


PETROLEUM  PRODUCT  CODES 


TABLE  C-5 


UTILITY  PRODUCT  CODES 


Product 

Product  Code 

Electricity 

ELC 

Natural  Gas 

NAG 

Coal  (Bituminous) 

COL 

Coal  (Anthracite) 

ANC 

Purchased  Steam/ 

SHW 

Hot  Water 

Fuel  Oil-Distillate 

DF1,  DF2,  FS1,  FS2,  KSN,  KDS,  NSF 

Fuel  Oil-Residual 

FSA,  FS5,  FS6,  FSL 

Fuel  Oil-Mixed 

FSX 

Photovoltaic 

PHO 

Solar  Thermal 

SOL 

Wind  Power 

WND 

Wood 

WUD 

Geothermal 

GEO 

Geothermal  Electricity 

GLC 

Propane,  Butane,  LPG 

PPG 

Refuse-Derived  Fuels 

RDF 

Hydroelectric 

HYD 

Fuel  Oil  Reclaimed 
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